Web portal pages have become an increasingly popular means of delivering aggregated content to computer users. Typically, a portal page is created on a portal server by a portal program (e.g., WebSphere Portal Server from International Business Machines Corp. of Armonk, N.Y.). As known, a portal page includes sections or visual portlets that each contain particular portal content arranged in a certain format (e.g., look and feel). For example, referring to FIG. 1, a portal page 10 could be established that has sections for Stocks 12A, Breaking News from AP 12B and Technology News from Reuters 12C, as well as various advertisements 14A-C. When page 10 is requested by an end user, the portal program would obtain the desired portal content from the appropriate content providers. Once obtained, the portal content would be aggregated, and then displayed in the appropriate sections as portal page 10. Thus, the provider of a portal page need not maintain the actual content itself. Rather, it need only obtain the requested content from the appropriate sources upon request.
This advancement of portal technology is not only being used for the creation of personalized “home” pages by individual web users (e.g., MY.YAHOO.COM), but is also being implemented by many organizations (e.g., businesses) as a more efficient way to deliver content to end users in a certain format (e.g., look and feel). For example, a particular organization such as a bank might maintain a portal-based web site that includes portlets for a stock ticker, financial news, a mortgage calculator, etc. These portlets could formatted to have certain characteristics (e.g., color patterns, stylization's, etc.) that are unique to the particular organization.
Unfortunately, as convenient as portal technology can be, it is not without drawbacks. For example, whenever an organization wishes to add a new function to its portal page, a new portlet must be created. Since each portlet essentially functions as an application, each new portlet must typically go through an extended development and deployment process. This has been the case even though there may be a high degree of commonality between portlets. That is, a number of portlets may actually perform the same function, just on different sets of data. For example, if portlet “A” provides sports news, while portlet “B” provides business news, the underlying function of both portlets would be to retrieve a certain type of data from a certain source. As such, there might not be a need to repeat the lengthy development and deployment process for portlet “B” once portlet “A” has been deployed. Even if portlet templates are used to create duplicates of a certain portlet, each duplicate is still considered a separate application that must endure the development and deployment process.
In view of the foregoing, there exists a need for a more model driven portlet development process. To this extent, a need exists for portlet behaviors to be embodied as portlet patterns to which actual values can be bound, and instances of portlets can be created according to presentation templates.